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A COMMUNICATION NETWORK TERMINAL SUPPORTING A PLURALITY OF 
APPLICATIONS 

5 The present invention relates to a terminal for a communication network, the 
tenninal being capable of supporting a plurality of applications and having means 
of communicating user messages. The present invention also concerns a system 
in a communrcation network comprising transmitting terminals and receiving 
terminals being capable of supporting a plurality of applications, both of said 
10 terminals having means of communicating user messages. 

At present, communicators are being developed which, in addition to ondinary 
mobile station functions, also have data processing facilities, which enable, e.g., 
the maintenance of a calendar, and the sending of a fax message and electronic 

15 mail. The communicators nrray have or may support several different applications 
like organiser type devices. One type of communicator has been presented in 
Patent Publication US 5 422 656, comprising a user interface having a traditional 
alpha-numeric keyboard-like keyboard with which it is easier to type, e.g,. text 
messages. In the publication in question, the keyboard has been implemented by 

20 means of a touch display. However, as traditional mobile phones develop, 
especially as the user interface and displays develop further, also more advanced 
operations wtlJ be possible by a traditional mobile phone like device. 

Publication WO 94/23394 presents an electrontc greeting card communication 
25 system, comprising an electronic mail server for a communicator having different 
types of greeting cards, which can be browsed and sent to a similar 
communicator, for example, by using radio communication. A drawback of the 
system is that the greeting cards in question can only be sent to a similar 
communicator. Therefore, the sender should know whether or not the receiver has 
30 a communicator supporting the greeting card communication system. In addition, 
for the implementation of the system, an off-line elecfronic mail server, for storing 
different types of greeting cards, shouW be separately connected to the network 
for the service in question. Another drawback is that because the system uses 
ordinary radio communication to transmit greeting cards, the telephone line of the 
35 communicator is- engaged during transmission. By means of the communicator, 
presented in the publication, graphic images including hand written text can be 
transmitted. The transmission of such an image or a mere hand vinitten message 
is quite slow due to the large amount of information. Publication WO 94/23394 
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only discusses the sending of information relating to one application or service, i.e. 
a greeting card application. As communicator-like devices have several different 
applications a problem arises of how to send and handle information in relation to 
different applications. In the WO publication a separate electronic mail server has 
5 been arranged for the specific greeting card sen/ice. However, providing a 
separate electronic mail server for each application of a communicator would lead 
to a rather complicated and expensive solution. And even then one would face the 
problem of how to handle information relating to different services in the terminaJ 
device, e.g. in the communicator, 

10 

The present invention concems a tenninal for a communication network, the 
temiinal capable of supporting a plurality of applications and having means of 
communicating user messages wherein it comprises means for receiving user 
messages having data and a header relating to one of said applications and 

15 means for addressing the data to a respective application according to said 
header. Accordingly the terminal may readily have a plurality of different 
applications on such can be arranged into the terminal at a later stage. The later 
addition of applications can bo done by direct contact of over the air contact to 
another device/One user message may contain data relating to one application 

20 indicated by the header, or a user message couW contain data relating to several 
application, indicated by drfferent headers, e.g. so that the header indicating a 
specific application is followed by the data relating to that specific application. 

User messages contain a limited amount of information and are, therefore, quick 
25 to transmit. One type of user message is the so called short message. The 
invention is especially suitable to be implemented by the use of short messages. 
The mobile phone system according to the standard iS-136 uses a so called R 
data field for the transmission of similar short messages. Another type of a user 
messaging function known in the GSM system according to which SMS like 
30 messages can be sent as well is USSD (Unstructured Supplementary Service 
Data, which is more closely defined in the GSM specifications, e.g. in the following 
documents: TS GSM 02.04, TS GSM 02.30, TS GSM 02.90, TS GSM 03.38, TS 
GSM 03.40. A similar messaging form called SOC (Service Operator Code) exists 
in the mobile phone system according to the standard IS-136. Communication 
35 forms like SMS. R data, USSD and SOC are here called user messaging functions 
and the messages are called user messages despite the fact that such messages 
can as well be sent by an operator and not only by a user. The benefit with this 
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kind of cximmunication is that it does not reserve the voice call channel either at all 
or at least not continuously. 

Similar benefits exists in packet switched communication. A protocol based on 
PRMA (Packet Reservation Multiple Access) for relaying packet switched 
information is known in mobile communication networks. It is also called "Packet 
Radio". The PRMA is a technology for multiplexing packet formatted digital speech 
or data into a tinae divided earner wave. A packet radio sen/ice. GSM GPRS 
(General Packet Radio Service) under development for the GSM mobile radio 
system is used as an example. GPRS is a new GSM service offering packet radio 
service for GSM subscribers. GPRS reserves radio resources only when there is 
something to transmit, allowing the same resources to be shared by all mobile 
stations according to their needs. Accordingly also packet radio transmissions 
may be used for transmitting user messages, that reserve the communication 
channel for only short periods. 

The intention js that any user messages can be used, but in following mainly short 
messages will be referred to as an example. In addition to being fast to send, the 
advantages of a short message service can be utilised, such as not reserving the 
voice channel- Application related information can either be pre-stored In a 
terminal memory (permanent memory) or a user may store the application related 
information in a tenminal memory (cache memory) by contacting a server by 
means of a tenninal. Depending on the application, the user may enter user input 
or modify the infonmation in the applications, la another application the information 
relating to an application may be sent by a service provider and the information 
may be such that it is not possible for the user to modify it, only to request the 
service provider to modify it. The infonnation readily printed in the application can 
also be transmitted. An application type identifier or header is preferably added to 
the ti^nsmission. so tiiat a receiving terminal identifies the short message as not 
an ordinary short message, but as a short message containing information relating 
to and intended for a specific application. The identifier can be a code in an 
address or a control field of the short message, or it can be a code in the message 
part of the short message. Because it has been realised that the short message 
service, already existing in the mobile station system, can be utilised for sending 
information on applications, the advantages are, e.g., that there is no need to 
establish an off-line server for sending the application related information, such as. 
for example, in the system presented in Publication WO 94/23394, Espedally 
advantageous is that one and the same server, i.e. the SMS server (the Short 
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Message Service Centre SM-SC) can be used for sending and forwarding 
information relating to any application, so there is no need to have separate 
sen/ers for each application. The SMS sen/er will forward any short message and 
the temiinal will address the infonmation to the correct application according to the 
5 header or identifier in the message. And since a short message can be sent 
simuttaneously with a circuit-coupled connection, the sending of the application 
related infonmation does not engage the terminars communication line, e.g., in 
case of a simultaneously incoming call. A network like the GSM network is 
maintained by several operators and usually each operator has at least one SMS 
10 server of their own. In this case naturally any SMS server or several sen/ers may 
be used for the invention. 

A terminal according to the present invention is wherein it comprises means for 
receiving user messages having data and a header relating to one of said 

15 applications and means for addressing the data to a respective application 
according to said header. Another tenminal according to the present invention is 
wherein it comprises means for sending data relating to one of said applications in 
a user message and means for adding a header to the user message, the header 
indicating the respective application that the data relates to. Correspondingly, a 

20 system according to the present invention is wherein the transmitting terminals 
comprise means for sending data relating to one of said applications in a user 
message and means for adding a header to the user message, the header 
indicating the respective application that the data relates to, and the receiving 
terminals comprise means for receiving user messages having data and a header 

25 relating to one of said applications and means for addressing the data to a 
respective application according to said header. 

The invention will be discussed below in detail by refening to the enclosed 
drawings and appendices, in which 

30 

Figure 1 illustrates tine flow of a short message from one mobile station to 
another, 

Figure 2 illustrates connections of a mobile station system to a short message 
service centre, 

35 Figure 3 illustrates a user interface of an ordinary mobile phone. 

Figure 4a illustrates segmenting of a message into ficinnes in transmission, 
Rgure 4b illustrates reconstruction of a message in reception. 
Figure 5 lllustirates a frame of a short message. 
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Figure 6 illustrates one application according to the present invention. 
Figure 7 illustrates another application. 

Figures illustrates the transmission of the application related information, 
illustrated in figure 7, from the system's viewpoint, 
5 Figure 9 illustrates the implementation of the terminal according to the present 
invention, 

Figure 10 illustrates in sequence the function of one application in the terminal 

according to the invention. 
Figure 1 1 illustrates in sequence the function of one application in the terminal 
1 0 according to the invention, and 

Appendix 1 illustrates the application related information, illustrated in figure 7, 

presented in characters. 

In following the invention will be explained in more detail by using as an example 
1 5 one form of user message function, the short message service. For understanding 
the invention prior art relating to short messages will first be described by referring 
to Figures 1 - 5. and the embodiments of the present invention wilt be explained 
by referring to Figures 6-11, and to Appendix 1 . 

20 In digital mobile communications systems, as in the GSM system, it is possible to 
send so-called short messages. In the GSM system, this is known as the SMS 
(Short Message Service). Thus, in addition to telephone calls and data transfer, 
the GSM system also provides, in the fonn of a short message service, a paging 
system-like service. However, the short nnessage sen/ice known from the GSM 

25 system is considerably more advanced than an ordinary paging system. By means 
of a mobile station, text messages can be both received from and transmitted to 
another mobile station. One of the advantages of the short message service of the 
GSM system is also that the short message can be sent or received at the same 
time as an ordinary circuit-coupled communication is open. e.g.. during a call. 

30 Thus, the sending of a short message does not keep the mobile station engaged 
in case of a possible incoming call. 

The advantage of short messages as compared to telephone calls is that they can 
be sent to a receiver although the receiver cannot be contacted at the time the 
35 message is being transmitted. This has been implemented by dividing the 
transmission of the short message, from a first mobile station to a second mobile 
station, into two parts as illustrated in Figure 1: from a transmitting mobile station 
MS1 to a SM-SC (Short Message Service Centre), wherein the short message is 
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Stored and sent further to the actual destination, i.e., to a receiving nnobile station 
MS2. as soon as contacted. In Figure 2. the connection of the short message 
service centre SM-SC to a mobile station system has been illustrated in more 
detail. Below, the transmission and flow of short messages between different 
5 interfaces, known for prior art, will be discussed by referring to Figures 1 - 5. 

The structure of a mobile station system and connections for transmitting short 
messages are illustrated in Figure 2. Mobile stations MS are connected to base 
stations BTS by means of radio communication. The base stations BTS are further 

10 connected, through a so-called Abis interface, to a base station controller BSC, 
which controls and manages several base stations. The entity formed by a 
number of base stations BTS (typically, by a few dozen base stations) and a 
single base station controller BSC, controlling the base stations, is called a base 
station system BSS. Particulariy, the base station controller BSC manages radio 

15 communication channels and handovers. On the other hand, the base station 
controller BSC is connected, through a so-called A interface, to a mobile services 
switching centre MSC, which co-ordinates the formation of connections both from 
and to mobile stations. A further connection is made, through the mobile service 
switching centre MSC, to outside the mobile communications network. The 

20 aforementioned short message service centre SM-SC is coupled to the mobile 
services switching centre MSC, 

When a user wants to send a short message by means of the mobile station MS1 
{Figure 1), he/she writes a message to be transmitted (using a user interface of 

25 the mobile station) and gives the phone number of the mobile station MS2, i.e., an 
identifier of the mobile station MS2, whereto the message is going to be 
transmitted. In addition, the mobile station should have the contact information, 
i.e., the phone number of the short message sen/ice centre SM-SC. Normally, this 
has been stored in the memory of the mobile station, in which case it is not 

30 necessary to separately input the phone number in connection with the sending of 
each short message. Thus, when sending a short message, the message goes 
from the mobile station MS to the base station BTS. and from there, through the 
base station controller BSC and the mobile services switching centre MSC, further 
to the short message sen/ice centre SM-SC. The short message is stored at the 

35 short message service centre SM-SC, wherefrom it will be sent further to the 
receiving mobile station MS2, in which case the route of the message is the same 
as in transmission, but in the opposite direction. The short message service centre 
SM-SC will be infonmed whether or not the mobile station MS2 has received the 
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Short message. Thus, it can re-send the short message, if the mobile station MS2 
has not received it for some reason. 

Additionally short messages may be sent by a personal computer PC. In this case 
the mobile services switching centre MSG has a connection to a server GTW 
(Gateway), which has a connection to e.g. Internet. Thus a computer PC having a 
connection to Internet (or directly to the server GTW as shown by the broken line) 
may fetch a WWW (World Wide Web) page from Intemet. which physically can be 
found e.g. from the server GTW. Optionally a service provider or operator may 
have a separate server GTW having a connection to the mobile services switching 
centre MSG for sending short messages or other user messages. When using 
such a WWW page for sending a short message the user inputs the connection 
infomiatton (e.g. phone number) of the receiving terminal MS2 and the message 
to be sent whereby the message is transferred via Internet and the server GTW to 
the mobile services swrtching centre MSG and further to the short message 
sen/ice centre SM-SC from which the message is directed to the receiving 
terminal MS2 via the mobile network. 

By means of the short message service SMS of the GSM system, it is possible to 
send, at a time, a message the maximum length of which is 160 characters. The 
characters are seven-bit ASCII (American National Standa«l Code for Information 
Interchange) characters and. therefore, the maximum length of a message in bits 
is 1.120 bits, i.e.. 140 bytes. Ordinary mobile stations, as the one illustrated in 
Figure 3, have a small display and an advanced keyboard by means of which it is 
possible to wrrte short messages, i.e.. input different types of alpha-numeric 
characters. The received message is displayed on the display of the mobile 
station, which enables the display of alpha-numeric characters, as illustrated in 
Rgure 3. 

As is well known, transmissions in the GSM system have been divided into 
frames. When the length of a message to be transmitted exceeds the permissible 
maximum length of a frame FR, the message M must be segmented into parts Ml 
- M4. and sent in several frames FR1 - FR4. as illustrated in Figure 4a. In 
reception, the mobile station reconsfructs the message M. divided into several 
frames FR1 - FR4. as illustrated in Figure 4b. At a radio interface (Figure 2). the 
maximum length of a frame is normally 168 or 184 bits and. therefore, a short 
message, the maximum length of which is 1,120 bits, must be segmented into 
several frames. Figure 5 illustrates a frame, a so-called LAPDm frame (Link 
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Access Protocol for the Dm channel), to be transmitted at a radio interface, which 
has normally been divided into three fields. The first field is an address field ADD, 
which contains the address of the destination of the message (i.e.. a receiving 
mobile station identifier), given in several bytes. In the GSM system, signalling 

5 messages are also transmitted within corresponding LAPDm frames. In radio 
communication, there can simultaneously be two message flows independent of 
each other signalling messages and short messages. These two different flows 
are separated from each other by means of a service access point identifier SAPI 
to be added to the address field ADD. Its value can be 3. indicating signalling, or 

10 0. indicating a short message. The second field is a control field CTRL, which 
contains the sending frame and receiving frame numbers N(S) and N{F). The third 
field is a data field INFO, containing the actual information or data, which contains 
a maximum of 168 bits of information, i.e., the contents of the actual short 
message. 

15 

in the present invention, using short messages as an example, the transmission of 
each application related information will be identifred by means of a specific code, 
i.e., an identifier, which enables the receiving terminal to process the received 
message directly into an application, as specified, containing the received data. 

20 The identifier is preferably implemented by using ASCII characters in an 
information field of the short message transmission frame, i.e., in a field INFO 
(figure 5). which contains the actual short message in characters. Alternatively the 
identifier may be in the form of some other character or string code, such as bits, 
since for sending a short message the data is anyvray converted into bits. 

25 Because the information relating to the applications is transmitted in a short 
message, it can also be received by means of an ordinaiy mobile station, which 
does not support the application service, but is capable of transmitting and/or 
receiving short messages. By placing the application identifier in the field INFO, 
there is also the advantage that in an ordinary mobile station, which does not 

30 support this type of application service, but is capable of transmitting and/or 
receiving short messages, the application identifier is displayed to a user of the 
terminal, e.g. a communicator and. hence, the user notices not having received an 
ordinary short message, but the information relating to a specific application. In 
addition, a user of this type of ordinary mobile station can also t^nsmit a 

35 message, such as mentioned above, by first writing, on the message, the identifier 
of the application In question in characters, and the rest of the Information 
correctly divided. The reception of such a transmission by means of a terminal, 
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10 



according to the present invention, will produce a fully received application related 
information record. 

Alternatively, the application identifier is formed as a specific bit code in the 
address or inforniation field of the short message {see figure 5). Furthemiore. in 
this case, an ordinary mobile station can receive the transmitted information 
relating to the specific application, but the user cannot see. in connection with the 
message, that the received message is the information for a specific application. 
In this case, the infomiation for this type of application cannot be sent by means of 
an ordinary mobile station, unless it is modified, so that by entering a specific 
command, it will add the aforementioned bit code because, othenwise. the ordinary 
mobile station is unable to inform of the application identifier. 

Figure 6 illustrates an example of an application with an application record pre- 
15 stored in a temiinal. the user input information (the application record) on which 
can be^sent to another terminal as a short message. This application type is a so- 
called "Business Card". The application runs business card contents and contains 
the following infomiation: name, position, company, contact infbnnation. etc. Each 
information can be in its own field or the application may only have one field. 
0 whereinto all the infomiation is fed. Figure 6 also illustrates the transmission of the 
information on an application as a short message. In this case, an idertifter of the 
application type may be, e.g., 'BC* or 'Business Card' as illustrated in the figure. A 
terminal, according to the present invention, adds the application identifier (e.g. as 
letters or in other fomi) to the beginning of the infomiation field of the short 
5 message to be transmitted first The contents of the different fields ends 
automatically in a line feed character. On the basis of this character, a receiving 
terminal is capable of dividing the received information into the corresponding 
fields on the application, if this type of message was transmitted as a short 
message fnam an ordinary mobile station, a user would write, at the beginning of 
the message, an application Identifier, i.e.. in the case of Rgure 6. 'Business 
Card*, after that a line feed character [cr]. then the information on the application in 
succession or by field (depending on the application specification), i.e.. first the 
infonnation in the name field and a line feed character, etc. A received 'Business 
Card' can be stored in a memory of the terminal, where business cards can tinus 
be stored in an electiionic forni and can be retrieved from the memory and looked 
at by means of the Business Card application. The information in a Business Card 
application may of course vary depending on the device. In some temiinals it 
could mean e.g. only the name and phone number, which can be used as a Short 
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Dial application. Accordingly the invention could be used to update contents of a 
Short Dial application. In this way the user could make a backup of the contents of 
the Short Dial application by sending the contents to a service center for storage. 
If the terminal (e.g. a mobile phone) is later lost/stolen or destroyed in which case 
the user will have to acquire a new temiinal, he/she can in addition to activating 
the terminal, also download (retrieve) all Short Dial application contents to the 
terminal. Of course the same solution can be used for the contents of any 
application in the terminal. Several other applications will be explained here. 

In the following, as an example, other types of applications will be discussed. 
These applications can be pre-stored in a terminal or an-anged into the terminal 
(by programming) at a later stage. 

An application -Call Me Back" may contain a person's name, telephone number, 
address, etc., as well as a message that the person should call back. This 
information can t>e divided into separate fields or be in the same fiekJ. as 
presented above. The aforementioned message to call back may be inseparably 
linked to the "Call Me Back" application and/or "Call Me Back" (as text) can be 
written as an identifier, which will also be displayed on the display of an ordinary 
mobile station, in which case, a user of the mobile station in question receiving the 
message will see that it is a request to call back. The transmission of the "Call Me 
Back" application related information can be connected to an outgoing call, so that 
if the destination tenninal does not respond, the transmitting or calling temninal will 
ask the user (the caller) whether a "Call Me Back" notifier should be sent, in which 
case, if the user's response is positive, it will mn the application in question on the 
display with the telephone number of the caller (which it can access, e.g., from 
one's own SIM card. Subscriber Identity Module) ready input on the application 
data fields. The user may input the rest of the infomiation and modify it on the 
display by the "Call Me Back" application. When application related infomiation is 
sent as a short message, the temninal automatically offers the telephone number 
of ttis receiver as the destination of the message, wt^ch it can pick up from the 
infonmation of the call left unanswered. 

An identifier of an application 'Meeting Proposar can be "Meeting Proposal", and 
the infonnation in the application may contain a convenor's name, time and place 
of the meeting, as well as its subject If, in a terminal, there is also an electronic 
calendar application, the tiansmission of the application related infonnation in 
question can be connected to ttie functioning of the calendar application so tiiat. 
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as a response to the transmission of information related to this type of application 
(Meeting Proposal), a reservation for the meeting at the time In question is made 
in the caiendar. The specific application preferably picks up the time of the 
meeting from the application and enters, in the calendar, at the time in question, 
the rest of the infonnation on the application, such as the place and subject of the 
meeting, as well as the name of the convenor. Conrespondingly, when receiving 
this type of application related infonnation, the terminal automatically searches, in 
the calendar, for a statement of what may already have been agreed upon at the 
time in question (rf entered in the calendar). Thus, the receiver can quickly decide 
whether to answer 'Yes' or "No" to the meeting proposal. When such an answer is 
sent, the terminal establishes an application 'Meeting Prc>posaI Answer", whose 
identifier can be. e.g., 'Meeting Proposal Answer*, and the infonnation in the 
application may include a receiver's name, a time and place of the meeting, 
subject, answer (Yes/No), and comments. In this case, the caiendar application in 
the temnlnal of the receiver, i.e., the sender of the meeting proposal, is preferably 
arranged, so that it either confimns or cancels the resen/ation made in the 
calendar. 

Furthennore. as a continuation for the 'Meeting Proposal' application, there may 
be. in the terminal, an application 'Meeting Confirmation', whose identifier is. e.g.. 
'Meeting Confirmation', and the Information in the application may contain a 
convenor's name, a time and place of the meeting, and its subject The tenninal 
preferably offers to send this application related infonnation automatically to all 
those who answered 'Yes' to the meeting proposal. In this case, the mobile 
stations or communicators receiving the infonnation related to this application will 
confirm the reservation in question in the calendar. 

Conespondingly, in the same way as with the 'Meeting Proposal' application, other 
similar applications can be arranged in the temiinal. e.g., an application 'Free 
Time Query, whose identifier can be, e.g.. 'Free Time Query*, and the information 
in the application may contain a sender's name, a time, a place, and a subject, 
which a user may freely fill in, e.g., tennis, dinner, etc. 

The tenninal preferably functions in tiiis connection in the corresponding way, both 
in b^nsmission and reception, as In connection with the meeting proposal 
applications. i.e.. it makes a reservation in tiie calendar, enables the response to a 
query by means of another application, and. furthennore, enters in the calendar a 
possible confirmation or cancellation. 
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By means of an application 'Service DTMF Commands', information can be 
received, e.g., from a network operator in order to utilise services provided by the 
operator. An application identifier can be 'Service DTMF Commands', and it may 
have fields for a sender's name, a DTMF command, and an explanation field. The 
command can be, e.g.. a password, a user identifier, or something else related to 
the services provided by the operator. A user may use the received command, 
e.g., a password, when utilising the offered services, in which case, the user does 
not have to input the password through the keyboard, because the password can 
be obtained directly from the application (or the information in the application) in 
question. Other applications to which infomiation may be received from a network 
operator are any applications which require some settings in the tenminal before 
an application can be used. An example is an 'internet Access Point' application 
which contains infomiation necessary for the terminai to use a WWW browser for 
example. This information may be provider name, phone number, modem 
initialisation information, server information, IP address (Internet Protocol). 
Another example of an application that needs some settings is a Fax Box 
application. Afaxbox is a sen/ice implemented e.g. in a server, which receives all 
faxes for a specific user. The user can then retrieve the faxes from the faxbox. For 
retrieving faxes the tenninal needs to have the contact information to the server. 
This could be Implemented so that when the tenninal has received a new fax to 
the faxbox, the tenninal receives a notification in a user message of a received 
fax. but additionally the user message would include a U1D infomiation (Unique 
Identifier), i.e. contact information to the faxbox server and other necessary 
infomiation, such as filename of the fax and a password needed. The Fax Box 
application could function either manually, i.e. by user execution, or automatically 
so that the tenninal contacts the faxbox server automatically for retrieving a 
received fax according to the identifier Information contained in the notifying user 
message. The contact can be made as fax call to retrieve the fax. Optionally it 
could be a user message sending the identifier information back to the server and 
additionally the fax connection, number of the terminal so that the server then can 
contact the terminal for sending the received fax to it via a fax call. 

Another sunt)unding for use of the invention is for solutions relating to intelligent 
traffic systems, which use mobile station like devices as terminals. The tenminal 
acconJing to the invention" may ttiereby have different traffic related applications. 
One example is a 'Position' application with whk:h position requests and 
responses may be sent/received in user messages according to the present 
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as a response to the transmission of information related to this type of application 
(Meeting Proposal), a reservation for the meeting at the time in question is made 
in the calendar. The specific application preferably picks up the time of the 
meeting from the application and enters, in the calendar, at the time in question, 
the rest of the information on the application, such as the place and subject of the 
meeting, as well as the name of the convenor. Correspondingly, when receiving 
this type of application related infonnation, the temninal automaticalfy searches, in 
the calendar, for a statement of what may already have been agreed upon at the 
time in question (if entered in the calendar). Thus, the receiver can quickly decide 
whether to answer 'Yes' or 'No' to the meeting proposal. When such an answer is 
sent the terminal establishes an application 'Meeting Prc>posaI Answer*, whose 
identifier can be. e.g., 'Meeting Proposal Answer', and the infonnation in the 
application may include a receiver's name, a time and place of the meeting, 
subject, answer (Yes/No), and comments. In this case, the calendar application in 
the temninal of the receiver, i.e., the sender of the meeting proposal, is preferably 
arranged, so that it either confirms or cancels the reservation made in the 
calendar. 

Furthemiore. as a continuation for the 'Meeting Proposal' applicatian. there may 
be. in the temninal. an application "Meeting Confirmation', whose identifier is. e.g., 
•Meeting Confirmation', and the information in the application may contain a 
convenor's name, a time and place of the meeting, and its subject The tenninal 
preferably offers to send this application related infonnation automatically to all 
those who answered -Yes' to the meeting proposal, in this case, the mobile 
stations or communicators receiving the infonnation related to this application will 
confimn the reservation in question in the calendar. 

Correspondingly, in the same way as with the 'Meeting Proposal' application, other 
similar applications can be arranged in the temiinal. e.g.. an application 'Free 
Time Query, whose kientifier can be. e.g.. 'Free Time Query, and the information 
in the application may contain a sender's name, a lime, a place, and a subject, 
which a user may freely fill in, e.g., tennis, dinner, etc. 

The temiinaJ preferably functions in this connection in the corresponding way. both 
in transmission and reception, as in connection with the meeting proposal 
applicaUons. i.e.. it nnakes a reservation In the calendar, enables the response to a 
query by means of another application, and. furthennore, enters in the calendar a 
possible confirmation or cancellation. 
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By means of an application 'Service DTMF Connmands', information can be 
received, e.g., from a network operator in order to utilise services provided by the 
operator. An application identifier can be 'Sen/ice DTMF Commands', and it may 
have fields for a sender's name, a DTMF command, and an explanation field. The 
command can be, e.g.. a password, a user identifier, or something else related to 
the sen/ices provided by the operator. A user may use the received command, 
e.g.. a password, when utilising the offered services, in which case, the user does 
not have to input the password through the keyboard, because the password can 
be obtained directly from the application (or the information in the application) in 
question. Other applications to which information may be received from a network 
operator are any applications which require some settings in the terminal before 
an application can be used. An example is an 'Internet Access Point' application 
which contains information necessary for the terminal to use a WWW browreer for 
example. This information may be provider name, phone number, modem 
initialisation information, server information. IP address (Internet Protocol). 
Another example of an application that needs some settings is a Fax Box 
application. Afaxbox is a service implemented e.g. in a server, which receives all 
faxes for a specific user. The user can then retrieve the faxes from the faxbox. For 
retrieving faxes the tenninal needs to have the contact information to the sen/er. 
This could be implemented so that when the terminal has received a new fax to 
the faxbox. the terminal receives a notification in a user message of a received 
fax, but additionally the user nr^essage would include a UID information (Unique 
Identifier), i.e. contact information to the faxbox server and other necessary 
information, such as filename of the fax and a password needed. The Fax Box 
application could function either manually, i.e. by user execution, or automatically 
so that the terminal contacts the faxbox server automatically for retrieving a 
received fax according to the identifier information contained in the notifying user 
message. The contact can be made as fax call to retrieve the fax. Optionally it 
could be a user message sending the identifier information back to the server and 
additionally the fax connection, number of the terminal so that the server then can 
contact the terminal for sending the received fax to it via a fax call. 

Another surrounding for use of the invention is for solutions relating to intelligent 
traffic systems, which use mobile station like devices as terminals. The terminal 
according to the invention' may tiiereby have different traffic related applications. 
One example , is a 'Position' appUcation with which position requests and 
responses may be sent/received in user messages according to the present 
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invention. Different solutions exist for determining the position. The application 
"Position" may contain position information of a specific address or point of 
interest as well as the description of the con-esponding position, a flag describing 
the reason or mode of transmission, and a reference number in case of a 
response message. After dividing the received information into the corresponding 
fields, the receiving terminal stores the received 'Position' application record in a 
local memory. The tenminal can also send Its own position or a stored position 
infonmation In a user message to another terminal or to a server. This can also be 
done automatically, e.g. in case of emergency situations. For emergency 
situations the terminal may have separate "Emergency Indication" or "Panic 
Indication" applications which automatically include infomiation about the sender, 
which the sender may modify in the application, about his vehicle and his position 
and other relevant infonnation needed for emergency situations. 

Additional applications for traffic purpose is for example Trip Request" and "Trip 
Response" applications (or generally 'Travel" application), which is a travel 
assistance application. In this application the temiinal can send out a Trip 
Request, preferably containing the actual position of the terminal as a starting 
point and a selected position out of the stored position application records for the 
destination of the trip. As a response to a Trip Request the tenninal may receive 
Trip Response' messages, which may contain instructions for the trip, such as 
turn instructions or public transport connections. 

Also the tenninal may have a Service application with infomation that can be 
Important for service purpose . such as the original serial number of the terminal, 
manufacturing month, repair month and month when modifications have been 
done (e.g. modifications to software). The informaton in the Service application 
can be sent in a user message from the terminal to for example the operator or a 
service station. 

Another possible application is a Phone Book application for sending phone 
number queries to a service provider keeping a Phone Book service. The query 
may include information like name, city of residence. landline/mobile number etc. 
As a response the sen/ice provider sends a user message which has the phone 
number or numbers and for example the infonnation that the user sent originally. 

Another type of application which will provide the terminal with many possibilities 
for having additional sen/ices and applications is a "Menu" application, in which 
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the terminal includes an application which is capable of creating menus in the 
terminal according to a received user message. The menus are preferably stored 
in a permanent memory, such as memory 14 in Figure 9 in order to create menus, 
which can be used permanently in the terminal. The user message contains 

5 information according to which the "Menu" application creates or updates menus 
in the tenntnaL This allows access to a big variety of services, which the operator 
can update in the user's terminal over the air. i,e. without the need for the user to 
take the terminal to a service place. Operators are provided with a very powerful 
tool to personalize the handsets their subscribers use. This tool is operator 

10 specific menu stmcture in the handset which can be different from subscriber to 
subscriber, if needed to. The menu structure can be dynamically updated over the 
air without any user assistance. In following is an example of menus that can be 
created and updated and which thereby can provide the user with additional 
services accessible by activating the command in a menu. Originally the terminal 

15 may include some basic menus or no menus at all. All the menus and sub-menus 
shown in the following example can be crated by sending a user message relating 
to the Menu application. 



MENU: 



Phone Settings 



20 



Operator Services 

Call Customer Service 
Download Ringing Tones 



Rock around the clock 



Those were the days 



25 



Smoke on the water 
Download SIM Software 
New Offerings 

<any operator specific supplemental service> 



30 



Local Services 

Join Wal Mart direct -ad 
Traffic at Dallas 1-75 
Thunderstorm Warning* 



35 



40 



Personal Services 
BigBook 
Yellow Pages 
Stock NOK A 
US Weather 
Send eMail 
Find Restaurant 
Holiday Travel Inc. 



Memory Settings 
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Accordingly the menu or menus can include main-menus and sub-menus as 
shown above, where the main menus Operator Services. Local Services and 
Personal Services include sub-menus. These sub-menus may further be divided 
into sub-menus, e.g. sub-menu Download Ringing Tones can be divided into sub- 
menus according to ring tone melodies (Rock around the clock, Those were the 
days. Smoke on the water) which can then be chosen as ring tones by selecting 
the specific sub-menu and activating it as a command. The command is sent to 
the ser/\ce provider as a user message according to the invention and as a 
response to the user message the operator may send the ring tone coded into a 
user message which can then be stored into a ring tone memory of the tenninal. 

Selections made in sub-menus cause wide variety of actions. Entries in the sub- 
menus can be associated with URL (Unifonn Resource Locater) information, 
which can be used to fetch information from internet, send email to Internet 
recipients, etc. In addition, supplementary services can be initiated directly from 
these entries; a special fomi of URL can be used to convey supplementary service 
related information or a call or user message. Actions may cause information to be 
sent to the tenninal by a network entity, e.g. enables selection and then 
downloading of ringing tones as explained above. Thereby the Operator Services 
menu can cause information to be fetched from Internet based on URL 
information, it can cause email message to be sent to a recipient, it can cause 
operator specific supplementary service strings to be sent to the network, or it can 
cause call initiation. The Local Services menu support services that are targeted 
to a specific geographical area. A menu is generated from Volatile' services that 
are available in a certain area, at a certain time. The users can browse through 
these services, and pick those that interest them. This facility provides an easy 
way to direct information (or advertisements of services) to phone users traveling 
through or in a geographical area. For example, one of the services. Traffic at 
Dallas 1-75' could become available as the phone user approaches the Interstate 
highway 75 in Dallas area. Instant traffic information can be achieved by selecting 
the sen/Ice from the menu. The Personal Sen/ices menu can be compared to the 
bookmari^ list in a normal WWW browser (World Wide Web). The phone users 
have the ability to add items to the list, to edit them, and to remove them. The 
Personal Sen/ices menu enables users to easily initiate wide variety of services. 
Service information can be moved from the list of operator specific or local 
services to the personal sen/ice list. Again. Personal Sen/ices menu can cause 
infbnnation to be fetched from the Internet based on URL infbmiation. it can cause 
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email message to be sent to a recipient, or it can cause operator specific 
supplementary sen/ice strings to be sent to the network or it can execute a call or 
cause a user message to be sent. For example the sub-menu command US 
Weather will result in the terminal receiving infomnation on the weather in the 
United States. 

Menu creation will be explained in more detailed in following. Menu creation is 
controlled and implemented by a processor and the Menu application which is 
stored in a memory and run by the processor. In following a protocol Is explained 
according to which the Menu application may be implemented as software run by 
a processor. The terminal will be described in more detail later in relation to Figure 
9. 

The protocol defines predetemiined commands according to which creation and 
change of menus and menu structures are controlled. There are four Item 
primitives in the protocol which are add. remove, list, and item capability. These 
item primitives will be accompanied by other menu-item definitions as will be 
explained. 

The first primitive item is item-add. which adds a menu or sub-menu. The 
command sequence may include following definitions, which can be sent to the 

terminal in a user message: 

<item-add> menu-item-token 

mcnu-group-name 

menu-ilem-name 

menu-item-type 

menu-itcm-help 

menu-action-Iist 

The definition menu-iterrvtoken can be an optional command to be used by the 
3 server for authorization purposes if security is needed, if not then it can be 

omitted. Once a menu Item has been sent to a terminal with a menu-item-token 
set, no command can be given to change or remove the existing menu-item 
without the same menu-item-token. This kind of authorization feature can be used 
in connection to other applicaUons described here as well, not just in relation to 
5 the Menu application. For example a ring tone would be updated only if it is 

accompanied by the correct authorization word or code, like the menu-rtem-token. 



wo 97/32439 



19 



PCT/n97/00119 



The first primitive authorization command, authorization-add. can be used to add 
one or more new authorized servers to the list of authorized servers for the given 
menu (menu-group-name). The menu-authorization-sen/er-list comprises one or 
more lines of information, each defining one authorized server. For GSM/SMS, an 
authorized server is defined by a pair defining identity of the short message 
service centre and of the server, e.g. (MS-ISDN of a SMSC which is the mobile 
subscriber intemational ISDN number for the SM-SC; MS-ISDN of the server, 
which is the mobile subscriber international ISDN number for the authorized 
server). The command sequence can be following: 
<authorization-add> menu-group-name 

menu-authori2aiion-server-list 



The second primitive authorization command, authorization-remove, can be used 
to remove one or more authorized sen/ers from the list of authorized servers for 
the given menu (menu-group-name). The command sequence can be following: 
<authorization-remove> mcnu-group-name 

menu-authorizarion-server-list 



The third primitive authorization command, authorization-list can be used to 
request the handset to send the list of privileged servers for a requested menu 
(menu-group-name). The availability of this command depends on the handset 
implementation. The command sequence can be following: 
<authoriz3tion-list> mcnu-group-name 

The Menu application has stored the meanings of different commands. This may 
be done for example in the fonn of a script interpreter as software in the terminal. 
An example of script interpreters is an interpreter understanding a specific 
programming language. Accordingly, when a specific command or sequence of 
commands is received in a user message according to the invention, the Menu 
application implements operations accordingly, such as adding or removing 
menus and/or sub-oienus. The above are to be treated as examples. Naturally 
different commands may be used than the above, and they may be shorter in 
order to fit more commands into one user message (e.g. into a short message). 

When using the Menu application with short messages the number of one or 
several short message sen/ice centres (SM-SC) can be related to a menu so that 
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when activating a user message by a menu item the message would be sent via a 
specific short message service centre or to any SM-SC of a specific list. The 
numbers of a specific or different SM-SCs can be sent from the network to the 
terminal in a user message, e.g. when a menu Is created or updated. This would 
allow more possibilities for services and quicker and more reliable transmission of 
user messages, when a special service (or the server providing that service) 
accessible via a specific menu command is connected to a specific service centre. 

An example of creating a menu for ringing tones is disclosed in Figure 10 as a 
sequence of displays to illustrate what the user sees on the display. The 
command "NEW RINGING TONES" is sent in a user message to a server of a 
ringing tone service provider in order to request for latest ringing tones. As a 
response the server sends a user message containing information relating to the 
Menu applications for creating a menu, from which the user can select a new 
ringing tone. The user selects the desirable" ringing. tone from the menu (selects 
ring tone 'Popcorn'). The selection activates a user message to be sent to the 
server indicating the desired ring tone. After a while the tenninal receives the ring 
tone from the server. A received ringing tone is indicated to the user using the 
"RINGING TONE RECEIVED" notification. The user can accept or reject the ring 
tone. Once the user has given acceptance, the selection menu with the options 
"Save" and "Playback" displays. If the user selects the Save -option the received 
ringing tone is saved to the phone and it appears to a ringing tone options menu. 
The saving is indicated to the user by displaying a "SAVED" confimaation note 
after which the phone goes to the idle state. If the user selects the Playback - 
option the received ringing tone is played to the user and after that the original 
selection list displays again. If the user gives a rejection of the new ring tone, the 
received ringing tone is discarded, the selection list is removed from the screen, 
and the phone goes to the Idle state. 

Another example of application of commands producing functions in a terminal will 
be described in following with reference to Figure 11. The example relates to 
querying the timetable of certain flights. First it is assumed that the user already 
has a created menu command for this purpose in the temiinal. which command 
the temiina! may have received according to the invention. The menu item 
F1NNAIR FUGHTS TIME-TABLE includes readily the contact information of the 
server to which the request is to be sent or If the terminal has a specific contact, 
then the request wiU be fon^varded from that contact to the server with the service 
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to be requested, i.e. the flight schedules. By activating the menu item FINNAIR 
FLIGHTS TIME-TABLE a first user message includes a code or signs which 
indicate sending a request, e.g. 

1) The first sent user message is following: 
5 ??? FLIGHTS 

where "??? FLIGHTS" is a command indicating to the receiving server that it is a 
request for Finnair flight time-tables. The user does not see the contents of the 
message but rather sees notes on the displays indicating that the request is being 
sent, that it has been sent and that the user shall wait for a while until a reply 
10 conries. These notes are shown after step 1) in Figure 11. After this the terminal 
receives a user message from the service provider, e.g. 

2) The first received user message is following: 
++Finnair flight queryCR 

<From:CR 
15 <To:CR 

<+Date: CR 

where indicates to the tenninal to wart for a reply and the text after that is 
displayed on the temninal screen for a while and CR (Carriage Return) ends the 
command row. The sign indicates a letter entry mode so the text after the 

20 sign is displayed on the terminal screen as seen in Figure 11 and it allows the 
user to enter letters. In this example OUL is entered indicating that the request 
concerns a flight from the city of Oulu. The user ends the entering by a 
predetemirned command (e.g. pressing of a specific key). Similarly a next entry 
mode indicating destination is showed on the display, whereby the user enters 

25 HEL entered indicating that the request concerns a flight to the city of Helsinki. 
The sign *<+' indicates a number entry mode so the text after the sign is displayed 
on the terniinal screen as seen in Figure 11 and it allows the user to enter 
numbers, which in this case is the date of the requested flight When the last 
command Is reached the terminal asks if the form is finalised and if the request 

30 can be sent, and if so the tenninal creates and sends a second user message 
containing the entered inforination, e.g. 

3) The second sent user message Is following: 
++Finnair flight queryCR 
<From:OULCR 



35 <To:HELCR 
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<+Date: 041296CR 

which the service provider (server) is able to interpret according to the 
predetermined commands. Again the user does not see the contents of the user 
message, but is displayed predetermined notes on the terminal screen. As a 
5 response to this request the terminal receives a second received user message 
from the service provider, e.g. 

4) The second received user message is following: 

Fmnair flights from OUL to HEL 04/1 2/96 :CRAY3434, 06:05 AY3436, 07:00 
AY3438, 07:30 AY3440. 10:15 
10 whereby the temiinal displays the relevant information (not the application specific 
codes) to the user as shown in Figure 1 1 allowing the user to scroll through the 
information (e.g. with arrow keys or other scrolling means) and as a response to a 
quit command from the user interface, returns to showing the original menu 
commands 

15 

The example described above and shown in Figure 11 illustrates how user 
messages according to the invention can be used for providing new services to a 
temninal, like a mobile phone, by having predetermined signs corresponding to 
predetermined commands. These signs and commands can be stored in a 

20 ' memory in the terminal device of a user (e.g. a mobile phone) or of a sen/ice 
provider (e.g. a computer) and can be implemented by software run by a 
processor for performing the predetemnined commands. Also in this wray the 
terminal can be programmed to function in a specific manner. The Menu 
application allows to introduce new applications into the temiinal. For example the 

25 previously mentioned Phone Book application could be introduced to the temninal 
by a first user message from the service provider creating a first menu (e.g. menu 
'Phone Book*) after which when sending a request to the service provider the 
temiinal would first receive a menu structure for sending the information needed to 
get the relevant phone number as was described earlier and after sending the 

30 relevant infomiation the terminal would receive a response including the phone 
number. This procedure could be similar to what was described above in 
connection to Figure 1 0 for querying the timetable for a flight. 

In the following, another application, which has not been pre-stored in a temiinal. 
35 will be discussed by referring to Figures 7 - 9, and to Appendix 1 . By means of the 
tenninal, electronic mail can be sent through a mobile communications network. 
Correspondingly, by means of tiie terminal, a communications link can be 
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established to the Internet through a mobile communications network. This 
communications link can be established by connecting a computer to a mobile 
station, by means of a data card, in which case a user interface of the computer 
can be utilised for reading pages and services on the Internet. Alternatively, a 
communications link to the Internet can be established by means of a 
communicator, which comprises in itself a user interface for reading pages and 
services on the Internet. A communicator of this type has been presented in 
Finnish patent application titled ■ 960894 filed on 26.2.1996 with corresponding 
patent applications claiming priority from the above and filed at the EPO on 
27.1.1997 with application number 97101184.6 and in the United States on 
23.1.1997, the description of which is incorporated herein by reference thereto. 
Computer programs by means of which a communications link to different pages 
on the Internet can be established, and which enable the so-called surfing on the 
Internet, are called WWW (World Wide Web) browsers. Currently, a number of 
different companies have their own service pages on the Internet, through which a 
user may order information on a service or make orders and reservations. This is 
accomplished by establishing communication to such a service page and by 
inputting infomnation on what is required from the provider of sen/ices. This 
information can be either text or selection boxes/keys, by means of which 
selections are made acconling to the 'tick the appropriate box' principle. An 
example of such a service page has been given in Rgure 7a, which illustrates a 
query page for bus schedules, which a user can download onto the display, e.g., 
through a telecommunications network, such as the Internet. In this case, the 
page will be stored in the communicator's memory (e.g., hidden memory) for the 
duration of the use of the page, and it can be stored in the permanent memory by 
means of an off-line command. On- the page, selections can be made in boxes 
and additional requests and. for example, contact infbnnation for feedback, can be 
written in the space that may be available on the page. Altematively. the 
communicator may automatrcaily offer its own telephone number as the address 
for the feedback, as presented above in connection with the "Call Me Back" 
applicaUon. As is known, a page on the Internet can be presented in the HTML 
language (Hyper Text Markup Language. Transforming and presenting a service 
page from the Internet in the HTML language is known from WWW browsers. 

Appendix 1 illustrates the Internet page in Figure 7 transformed into the HTML 
language in order to present the page in characters. The characters can be sent in 
a short message. In the GSM system, a message, whose maximum length is 160 
characters, can be sent in a short message. Therefore, in the present invention, a 
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whole page is not preferably transmitted, but only certain information of ft. In the 
HTML code on this service page, both the information to be displayed on the 
display and the hidden information have been specified. Different types of data 
have pre-set codes. To send the page according to the present invention, 
information necessary for the sending of an application related information is 
added to the HTML code of the page, and this information is hidden from a user, 
i.e., it will not be included in the graphic presentation of the page. The infonnation 
has preferably been arranged on the page by the provider of services. Thus, in 
order to be able to send such a service page as a short message, the provider of 
services should support the opportunity in question by including in the page in 
question specific information, at least the telephone number to which a message 
should be sent. At arrows A- J. illustrated in Appendix 1, there has been given 
infonnation. which is added to the HTML code in order to send the infomiation on 
the page in a short message according to the present invention. For example, at 
the an-ow A, a coding method can be indicated by means of a presented 
specification. The arrow B indicates that the typo of the form Is a query: the arrow 
C gives the name or abbreviation of the provider of services; the amsw D indicates 
the type of service in question; the an-ow E gives the name of the service page; 
the arrow F indicates which form the temiinal should use to display the answer 
the arrow G gives the telephone number of the receiver, i.e., the provider of 
services; the arrow H gives the telephone number of a short message service 
centre through which the message is transmitted. The information indicated by the 
arrows G and H is essential, at the least The arrows I and J indicate other 
specifications, which can be added on the HTML page as necessary. After the 
arrow J comes the actual HTML code that fomns the WWW page in question. 

Con^spondingly, a temiinal can be pre-set to find specific identifiers in the HTML 
code, which It picks up from the HTML code and attaches as characters to the 
data field INFO of the message to be sent (see figure 5). For example, a selected 
time is found on a line indicated by an an-ow K as a variable do. after which the 
selected time is presented, which will be obtained as a response to a press of the 
SEND button. As illustrated in Figure 7, an uppemiost selection box "1B1" has 
been marked, which is shown in the HTML code on a line indicated by an arrow L 
as a code checked. When a user presses the SEND button, a variable opti will 
get the value of the selection box. which has been selected when pressing the 
icon. i.e.. the value "181". assuming that the uppermost selection box has been 
selected. 
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In the exampte. illustrated in Figure 7 and Appendix 1, a terminal such as a 
communicator may, in this way, pick up information from the HTML code on lines 
indicated by the arrows C, D. G, H. K. and L. The terminal will place, at the 
beginning, an identifier indicating the application type, here as an identifier 
"WWWSMS". In addition, from the point indicated by the arrow C, a service 
pnavider identifier, on the basis of which the receiver will recognise the information 
in question, e.g., here a character C, can be placed in front Furthermore, the 
service name can be placed correspondingly from the point of the arrow D, the 
telephone number of the sender from the point of the arrow G, the telephone 
number of the receiver from the point of the arrow D. and the selections made by 
the user from the points of the arrows K and L, which functions, so that the values 
of ail the variables (here variables c/o and opti) on the page are placed in the 
message. The values of the variables are preferably obtained as a response to a 
send command, i.e., to a press of the SEND icon. In this case, the data sent in the 
short message are. e.g., as follows: 

WWWSMSCcr] 

CErSa[fl 

DTreBus[f] 

G+358505337397[f] 

H+35850877l010[fJ 

08:00 1B1 

,in which the [cr] character indicates a line feed and the [f] character is a field 
separator, which indicates the ending of the field and. on the last line, ail the 
selections made by the user are shown, i.e.. that the user requests information on 
the timetable of the buses of the line 1B1 (Holvasti-Keskustori) departing after 
08:00 o'clock. On the basis of this, the provider of services is able to send to the 
user information on ttia fmetable of the bus line in question. 

When this type of service page has been downloaded from the Internet, it can 
then be stored in the memory of the tenminal. and later re-used without 
establishing a communications link to the Internet Con^spondtngly, as to 
appfication related infomfiation pre-stored in the temiinal. a specific identifier can 
be attached to the message, in connection with the sending of the information on 
the application illustrated in Figure 7 and Appendix 1.. which indicates that the 
application is a sen/ice page downloaded from the Internet e.g., the identifier 
•WWWSMS' as in the exampte discussed above or 'WWWSMS45'. in which the 
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beginning indicates that it is a service page and the last two characters may 
indicate, e.g., the provider of services. 

Sending infornnation of a service page in a short message according to the 
5 present invention saves considerably the power consumption of the terminal and, 
thus, prolongs its useful life, which is an important objective in battery-operated 
devices. In addition, savings are made in phone call expenses, when query 
information can be sent together with the short message. The whole system has 
been illustrated in more detail in Figure 8. A terminal according to the present 

10 invention has been presented with reference numeral 1, by means of which a 
communications link (reference 101) to the Internet INT can be established. The 
invention could also be implemented by means of a device having means, 
according to the present invention, for processing information on an application 
into a short message, which is sent through ah ordinary mobile station by coupling 

15 the device to the mobile station. Such a device could be. e.g., a computer. To 
simplify matters, only a communicator will be discussed here as an example of a 
terminal according to the invention. When the communications link Is established 
to the Internet by means of a communicator 1 , a sen/ice page of a provider of 
services can be downloaded (reference 102) from the Internet into its memory and 

20 user interface. By means of solutions known for prior art, the user, after having 
filled in the page, has sent the sen/ice page by means of the communicator 1 to a 
server SERV of the provider of services, i.e., along route 101 - lOV. This means 
that the communications link to the Internet should be open for transmission. In a 
system according to .the present invention, the Information on the sen/ice page is 

25 sent (reference 103) in a short message to a short message service centre SM- 
SC, which sends it further (reference 104) to the server SERV of the provider of 
services. The transmission of the service page through the Internet, according to 
prior art, lasts considerably longer than the transmission of a short message and, 
thus, due to the present invention, a shorter transmission time is achieved, 

30 thereby, effecting a saving in power, since, in the communicator, transmission and 
reception, in particular, consume a lot of power compared to other functions. In 
addition, in the solution according to prior art, a circuit-coupled connection is in 
use in transmission, in which case the communicator is engaged during 
transmission. On the other hand, the sending of a short message does not 

35 engage the ctrcuit-coupied connection, and an additional advantage is that the 
short message service centre SM-SC will send the message to a receiver later, if 
the telephone number of the provider of sen/ices happens to be unreachable 
during the transmission of the message. 
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When the user has in this way sent the provider of services a query, the provider 
of sen/ices will interpret it and respond to it. The provider of services may also 
send the response (reference 105 - 106) as a short message, and it can, in the 
same way as in the transmission of the service page, contain HTML codes, which 
the communicator will interpret and transfomi into a form legible to the user. Thus, 
the sending of a response has the same advantages as the sending of an query. 
For the response, the original sen/ice page downloaded from the Internet, can be 
anranged on the display by the application njnning HTML code pages, so that it 
has space (fields) ready for the response. When the user sends the query to the 
provider of services, he/she stores the page in the communicator. The response 
win have, in the same way as in transmission, specific identifiers, in which case, as 
the response arrives, the communicator will run the specific application and open, 
on the display, the page in question and place the response in the area provided 
for it, whereupon the situation from the user's viewpoint looks as if he/she has 
received a WWW page containing the response. The response from the provider 
of services can also be, e.g., in a form of an application 'DTMF Sen/ice 



Instead of an application identifier being indicated as a code in a short message 
(in data field INFO), it can be indicated in an address field ADD of the short 
message, in which case it is given in bits. A certain byte in the address field of the 
transmission frame of the short message is a so-called TP-Data-Coding-Scheme, 
which has been specified in the GSM specification as GSM 03.40 and 03.38. The 
four less significant bits of the byte can be freely used, whereupon they can be 
used to indicate the type of the application to be sent according to the present 
invention. Different types of applications can be indicated by means of these four 
bits according to the example given in the following table, wherein bits are marked 
with references b3 - bC, in which bO is the least significant bit (LSB) of the 
aforementioned byte: 

b2 bo b, bn type 

0 0 0 0 Business Card 
0 0 0 1 Call Me Back, 
0 0 10 Meeting Proposal 



Commands' or in a corresponding form. 



0 



0 



1 



1 



Meeting Proposal Answer 
Meeting Confirmation 
Free-TimeQ uery 



0 



1 



0 



0 



0 



0 



1 
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0 110 Position 

0 111 Trip request 

1 0 0 0 DTMF ServiceCommands 
10 0 1 Menu 

5 1 0 10 WWWSMSOI 

10 11 WWWSMS02 

110 0 WWWSMS03 

110 1 WWWSMS04 

1110 Phone Book 

10 1 1 1 1 Short Dial 

Identifying the application in this way does not take the space reserved for the 
character length (max. 160 characters) of the message. When this type of 
identification is used, it is also possible to receive the information on the 

15 application sent by means of an ordinary mobile station, but in this case, the user 
is unable to see, in connection with the message, that it is the Infomnation from a 
specific application, unless this infomiation is programmed in the mobile station. 
Neither can the infonnation on this type of application be sent by means of an 
ordinary mobile station, because the user is unable to add this type of identifier to 

20 the message. Naturally an ordinary mobile phone does not support the different 
applications. 

In the following, the implementation of a terminal, in this case a wireless terminal 
according to the present invention, and its operation in transmitting and receiving 
25 an application related infomiation will be discussed in more detail by refening to 
Figures. 

In Figure 9, there Is a block diagram of the implementation of a terminal according 
to the present invention, which in the figure is shown as a device also having 

30 means for transmission over the air such as a mobile phone. However a similar 
implementation can be used for a terminal device of a service provider which 
usually does not have means for direct radio frequency transmission but is 
connected to such means (e.g. a base station) over the network as is shown in 
Figure 2 (e.g. the personal computer PC or server GTW). The tenninal is 

35 preferably a mobile phone or communicator, which has circuits and a user 
interface that enable the processing of different applications. The tenninal 1 in 
Figure 9 comprises, for communication using radio communication, a radio unit 
RU (the reference has not been marked in the figure), which comprises a 
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transmitter branch 2, known from an ordinary mobile station, (comprising blocks 
implementing coding, interleaving, ciphering, modulating, and transmitting), a 
receiving branch 3 (comprising receiving, de-modulating, de-ciphering, de- 
interleaving, and implementing blocks) and, for transmission using radio 
5 communication, a duplex firter 4 that distinguishes between a received and 
transmitted message, as well as an antenna 5. The temirnal has a main control 
circuit 6 that controls its operation, Furthemnore, the main control circuit 6 
comprises still a RU controller 7 that carries out control functions of an ordinary 
mobile station. In addition, the terminal main control circuit 6 comprises blocks 8 - 

10 12 for carrying out the functions of a data processing unit of the temninal and for 
sending applicat'on related information as a short message according to the 
present invention. Thus, the blocks 8-12 can t>e said to form a data processing 
unit DU of the terminal. The controls of the radio unit RU and the terminal's data 
processing unit DU do not have to be integrated into the main control circuit but, 

15 instead, they could also be implemented apart from each other, so that the RU 
control circuit 7 is on the radio unit's side, and on the data processing unit's side, 
there is the DU processor 8, which is in connection with the RU control circuit 7 for 
establishing communication t>etween the radio unit and the data processing unit. 

20 In the implementation illustrated in Figure 8. a first memory 13 is coupled to the 
main control circuit 6. The first memory can t>e a volatile memory, e.g.. RAM, 
where the main control circuit stores in-use data. In addition, the terminal has a 
second memory 14, which is preferably a pemianent memory 14, wherein the 
terminal's application programs performing different kinds of services and running 

25 the different types of applications, other data essential for the functioning of the 
terminal, and any other data which a user wants to store permanently, are stored. 
Altematively. the application related infomnation can be stored off-line in a memory 
of an external smart card, coupled to the terminal, wherefrom there is a 
connection to the main control circuit 6. This type of smart card is known, e.g., 

30 from the GSM mobile communications system, as a SIM card (Subscriber Identity 
Module), which usually has storage, e.g.. for storing telephone numbers. In this 
case, new applicatrans can be updated in the terminal by simply updating the 
memory of the smart card. 

35 For viewing applications, the temninal has a display 15, and for inputting data, a 
keyboard or other input device 16, such as a touch display. 
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In the case where the data processing unit DU and the radio unit RU are 
implemented as functionally independent units, both of them should, however, 
have either conamon or separate memories 13. 14, and a user interface Ul. 
Communication between the units would be established by means of a connection 
5 between the DU processor 8 and the RU control circuit 7 which, in this connection, 
is referred to as an externa! control interface ECl. 

in the following, we will discuss the implementation and operation of the tenminal, 
when transmitting application related information. By means of the user interface 

10 Ul, the required application is brought onto the tenninars display, in which case, 
on the basis of 16 commands from input devices, the control circuit 7 retrieves 
from the memory 14, wherein applications 17, 18 programmably handling the 
application related information have been stored, the selected application stored 
therein onto the display 15 or retrieves a sen/ice from the telecommunications 

15 network as presented above. The application relating to a sen/Ice is processed in 
the DU processor 8, which also controls the transmission of application related 
information by maintaining corrtact with the RU control circuit 7, which controls the 
operation of the radio unit RU. An application contains information, as illustrated in 
Figure 6. The information can be in one or more fields, which have either been 

20 ready filled in (if a record of an application already^ containing Information was 
retrieved from the memory) or its data fields are empty, in which case a user may 
input infomnation in the fields by means of the input devices 16 or modify the 
information in the fields. When the application contains the required information 
and the user enters^ by means of the input devices, a command to send the 

25 application related infomnation, the DU processor 8 fomns, from the information on 
the application, a line of characters, so that it places at the beginning of the line 
the application identifier (unless the identifier is given in the address fieW). and 
after that, e.g., the information contained iii the different fields, separated by line 
feed characters, in alpha-numeric characters including the possible space 

30 between the characters. Hence, the DU processor 8 comprises, for the processing 
of the characters, word processing program-like functions, which have been 
implemented by programming and stored in the memory 14, wherefrom the DU 
processor 8 retrieves the program and performs the functions according to the 
program. The DU processor 8 transfers the line of characters formed to a SMS 

35 transmission controller 10, which adds to the message address information, i.e., 
the information on the destination either on the basis of the user input information 
or by retrieving it from another application, e.g., from the calendar application as 
presented above. Thus, this type of SMS transmission controller is a kind of bit 
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and/or character generator. The calendar is preferably implemented as an 
application program, stored in the memor/ 14, which is used by means of the DU 
processor 8. Thus, communication between two different applications 17 and 18 is 
established by means of the DU pnx^essor, which thereby, e.g., on the basis of 
5 time information retrieved from one application, opens up or enters information in 
the other application (e.g. in the calendar at the time in question). 

When address information has been added at a SMS transmission controller 10, 
the message is transferred Into an Inbox 11, which tries to send the message, and 
10 which has a buffer wherein the message is stored in case the transmission fails. If 
the transmission fails, the inbox 1 1 re-tries to send the message. When the DU 
controller 8 notices that the radio unit RU is ready to send the message, the 
message is transferred to a message transfer running circuit 12. which adds to the 
message irrformation relating to the mobile communications system in question, 
15 such as validity information (which indicates to which direction the message is 
going, i.e.. from a mobile station to a message service centre or vice versa), 
processes the address information into a fonn required by the mobile 
communications system, and adds to the message the address of the message 
service centre, as welf as the short message identifier (SAPI), and forms from the 

20 information to be transmitted, e.g., a digital signal for a transmitter 2, and sends 
the message to the radio transmitter branch 2 of the radio unit RU. In the case 
where the application identifier is placed in bits in the address field ADD, the 
ojnning aYcuit 12 adds to the message the identifier in question. The transmitter 
branch 2 codes the signal according to the specifications of the mobile 

25 communications system, and forms, on the basis of the signal it receives fn^m the 
running circuit 12, the frames to be transmitted, which the transmitter sends using 
radio communication to the short message service centre SM-SC. wherefrom they 
are sent further to the receiver (see Figure 1). In the transmitter branch 2. the 
message is processed according to the mobile communications system, e.g., 

30 coding, interleaving, dphering. burst fomning. modulating, and transmission. 

In the following, we will discus the implementation and operation of the terminal in 
receiving application related information. When the tenninal receives a short 
message containing information for an application, the message first arrives at the 
35 radio unit RU. There, at a receiving branch 3, the processing of the message 
takes place according to th& mobile communications system, such as reception, 
demodulating, de-ciphering, de-interleaving, and decoding. If the received frame 
identifier (SAPI) indicates that the message is a short message, it will be 
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transferred into a destination box 9 of the data processing unit, which can be a 
memory for storing the message. If the received message is an ordinary short 
message, the DU processor 8 will report the short message received. If the 
message has an identifier, which indicates that it is an application related 
5 message, the DU processor 8 will launch the application 17. 18 in question, and 
place the information, from the received message, in the application in accordance 
with the markings on the received message. Hence, the reception of the user 
message {e.g. short message) will be displayed to a user as received application 
related information. 

10 

A terminal according to the present invention provides a simple way of transmitting 
and receiving application related information. Also the present invention provides 
a terminal that can have access to a enormous amount of service, e.g. by using 
the described Menu application. By especially using short messages as 
15 communication form the reaching of the destination is guaranteed, and with the 
user messages in general an optimum current consumption is achieved. The use 
of an authorisation token in relation to a user message describes a new method of 
adding security to a user message. 

20 This paper presents the implementation and embodiments of the invention with 
the help of examples. It is obvious to a person skilled in the art, that the invention 
is not restricted to details of the embodiments presented above, and that the 
invention can be implemented in another embodiment without deviating from the 
characteristics of the invention. Thus, the presented embodiments should be 

25 conskiered Illustrative, but not restricting. Hence, the possibilities of implementing 
and using the invefition are only restricted by the enclosed patent claims. 
Consequently, the various options of implementing the invention as determined by 
the claims, including the equivalent implementations, also belong to the scope of 
the present invention. 
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Appendix 1 

<head><titIe>VWVW SMS TRE NEXT BUS</title></head> 
<html><body> 
<form MEnHOD="SMS" 
5 ACTION="Nor>e" 
A-» ENCTYPE="b6" 
> 

<SMS_FORMJNFO 

B-^ FORM_TYPE=''Req" 

10 C-^ PROVIDER="ErSa" 

SERVICE='TreBus" 

E-> FORM_NAME=TBReq" 

F^ RESPONSE_FORM='TBRes" 

G-» TARGET_NUMBER="+358505337397" 

15 H-*- SERVICE_CENTER="+358508771010" 

l-> FIELD_NAMES=:"N" 

J-» PROTOCOL-ID="None" 
> 

<h2><p al}gn=center>Tampere bus traffic SMS query</p></h2> 
20 <h1 ><p align=oenter>Tampere</h1 ></p> 

<table bgcoior=whtte width=95% cellspacing=2 border=2> 

<tr><td align=center>Select the bus line, the time of departure from the 

terminal for the next bus you want to know about, and then press 

'SEND'</tdx/tr> 

35 <tr><td align=center>Give the time, if you want to know the times of 

departure of the lines departing after a specrfic time, otherwise, select 
'Now' 

K-» <SELECT NAME="do">O8:00 

<OPT10N>Now 
30 <OPTION>05:00 

<OPTION>06:00 

<OPnON>07:00 

<OPTlON>08:00 

<OPTtON>09:00 
35 <OPnON>10:00 

<OPTlON>11:00 

<OPTlON>12:00 

<OPTION>13:00 

<OPTlON>14:00 
40 <OPTION>15:00 

<OPTION>16:00 

<OPTION>17:00 

<OPTION>18:00 

<OPTION>19:00 
45 <OPTION>20:0G 

<OPTION>21:00 

<OPTION>22:00 



suBsnruTE sheet (RULH 2Q 
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Appendix 1 

<OPTlON>23:00 
<OPTION>24:00 
<OPTlON>01:00 

</SELECT><P> 
</td></tP- 

<tr><td><input type=radio checked name="opt1" 
valije="1B1"><b>Line 1 Holvasti - Keskustori</b></td><rtP* 
<tp-<td><lnput type^radio name="opt1" value="1B2"><b>IJne 1 
Hamnaia - Keskustori<b><^></tr> 

<tr><td><inpLrt type=radio name="opt1 " value="1 B3"><b>Line 1 
Keskustori - Holvasti<b></td></tr> 

<tr><td><inputtype=radio name="opt1" value="1B4"><b>Line 1 
Keskustori - Harmaia<b></td></tr> 

<tr><td><input type=radlo name-'optl" value="2B1"><b>Line 2 
Keskustori - Rahola<b><Ad></tr> 

<tr><td><input type=radip name="opt1" value="2B2"><b>Line 2 
Keskustori - Rauhaniemi<b></tdx/fcr> 

<tP-<td><input type=radio name="opt1 " value="2B3"><b>Une 2 Rahola - 
Keskustori <b></tri></lr> 

<tr><td><inputtype=radio name="opl1" value="2B4'^<b>Une 2 

Rauhaniemi - Kfiskustori<bx/td></tr> 

<tr><td align=c8nterxh2><input type=submit 

value="SEND"></td></tr></h2> 

</table> 

</form> 

</body> 

</html> 



suBsrmnt sheet (pule 26) 
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Claims 

1 . A terminal (1) for a communication network, the terminal capable of supporting 
a plurality of applicatioris (17, 18) and having means of communicating user 
messages, characterised in that it comprises means for receiving user messages 

5 having data and a header relating to one of said applications (17, 18) and means 
(8) for addressing the data to a respective application according to said header. 

2. A terminal according to daim 1, characterised in that said user messages are 
short messages and said data comprises characters in the short message. 

10 

3. A terminal according to claim 1 . characterised in that it comprises a memory 
(14) for storing data, and that one of said applications (17, 18) is a menu 
application, said menu application creating menu items in the terminal memory 
(14) according to predetermined commands, the terminal having means for 

15 receiving commands relating to the menu application in said user messages, 

4. A terminal according to claim 1 , characterised in that said data includes an 
authorisation code and the terminal has means (8) for allowing and prohibiting the 
addressing of the data to the respective application on basis of said authorisation 

20 code. 

5. A terminal (1) for a communication network, the temriinai capable of supporting 
a plurality of applications (17, 18) and having means of communicating user 
messages, characterised in that it comprises means for sending data relating to 

25 one of said applications (17, 18) in a user message and means (8) for adding a 
header to the user message, the header indicating the respective application (17, 
1 8) that the data relates to, 

6. A terminal according to claim 5, characterised in that said user message is a 
30 short message and that the terminal comprises means (8. 10 - 12) for processing 

the data into characters and for sending the data in a short message. 

7. A system in a communication network comprising transmitting terminals and 
receiving terminals capable of supporting a plurality of applications, both of said 

35 terminals having means of communicating user messages, characterised in that 
the transmitting terminals comprise means for sending data relating to one of said 
applications (17. 18) in a user message and means (8) for adding a header to the 
user message, the header Indicating the respective application (17, 18) that the 
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data relates to, and the receiving terminals comprise means for receiving user 
messages having data and a header relating to one of said applications (17. 18) 
and means (8) for addressing the data to a respective application acconding to 
said header. 
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Figure 3 
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Tampere bus traffic SMS query 



Tampere 



Select the bus line, the time of dcpartxire fh)m the terminal 

for the next bus you want to loiow about, and then press *SEND' 


Give the time, if you want to know the times o 
after a specified time, otherwise select "Now' 


f dcpar 
08:00 


aire 


of the lines departing 


^ Line 1 Hoivasti - Ket knstori 


- Now 
05:00 


▲ 




O Line 1 HirraSIii - Keskiutori 


06:00 




O Line 1 Keskustori - Holvasti 


07:00 




O Line 1 Keskustori • HflnnSlfi 
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0&£00 
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O Line 2 Rahola - Keskustori 




O Line 2 Raahanicmi - Keskustori 




1 SEND 1 
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